敏捷开发 小记
文章目录
第一部分 敏捷开发
人与人之间的交互式复杂的，并且从其效果从来都是难以预期，但却是工作中最为重要的方面
—人件
构建起具有合作精神的自组织团队
教堂尖顶傻姑娘的风标，即使由钢铁制成，如果不懂得顺应风势的艺术，一样会被风暴立即摧毁
——海因里希-海涅
让软件团队具有快速工作、响应变化能力的价值观和原则。
敏捷宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
为下两周的做详细计划，为下三个月做粗略计划，再为以后做极为粗糙的计划。
敏捷原则：
- 我们最优先要做的事尽早的，持续的交付有价值的软件来使客户满意
- 即使到开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创建竞争优势。
- 经常性的交付可以工作的软件，交付间隔可以从几周到几个月，交付时间间隔越短越好。
- 整个项目开发期间，业务人员和开发人员必须天天在一起工作。
- 围绕被激励起来的个人来构建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作。
- 团队内部，最具有效果且富有效率的传递信息的方法就是，面对面的交谈。
- 工作的软件事收腰的进度度量标准
- 敏捷过程提倡可持续的开发速度，责任人，开发者，用户应该能够保持一个长期的，恒定的开发速度。
- 不断的关注优秀的技能和好的设计会增强敏捷能力
- 简单—使未完成的工作最大化的艺术—是根本。简单
- 最好的架构、需求和设计出自于自组织的团队
- 每隔和一段时间，团队会在如何更有效的工作方面进行反省，相对应的对自己的行为进行调整。
极限编程
xp，极限编程，是敏捷方法中的最著名的一个。
和客户反复讨论，以获取对于需求细节的理解，但不去捕获那些细节。
重构；不能容忍代码重复
重构是持续进行的，不是在项目结束，版本发布的时候
而是我们，要在每隔一个小时，或者半个小时就要去做的事情！！！
隐喻
极限编程是一组简单、具体的实践，这些实践结合起来形成了敏捷开发的过程。
计划
初识探索：客户会不断编写新的用户素材。
开发人员对这些素材进行估算，估算是相对的，不是绝对的。
大的素材进行拆分，过小的素材进行合并
用户能够安全的进行存款、取款、转账等活动
拆分为：
- 用户登录
- 用户退出
- 用户向其账户存款
- 用户从其账户取款
- 用户从其账户向其他账户转账
任务计划
一个任务，是一个开发人员能够在4～16个小时内实现的一些功能。
在迭代中的点；我们希望看到拥有一半素材点数的完整素材被完成。而不是完成了百分之90的素材点，确没有一个完整的素材被完成。
测试
烈火验真金，逆境磨意志——卢修斯-塞尼加
测试驱动
Mock object模式。测试方法
白盒测试
黑盒测试
重构
代码可读性，
去掉重复的代码
提炼
一次编程实践
如果还没必要引入新的类，先用简单参数。add(int) 二不是 add(Throw)这样。
单一职责原则。game接受投掷也知道如何计算每轮的得分，好像有点违反了单一职责原则，如果增加一个scorer对象呢？？暂时先放着。因为我们还没想好把分数计算放在哪里
先把代码写的更容易让人理解。
各种测试例过了之后，看到乱乱的程序，再来重构一下？？
从测试开始，至上而下
第二部分 敏捷设计
全局视。图和软件一起演化，在每次迭代中，团队改进系统设计，使设计尽可能适合于当前系统。不会花很多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才回需要的特性。
拙劣的设计：
僵硬化：设计难以改变
单一的改动导致有依赖关系的模块的连锁改动，必须要改动的模块越多，表示设计越僵硬化
脆弱性：设计易于遭到破坏
一个地方修改后，许多地方就可能出现问题
牢固性：设计难以重用
粘滞性：难以做正确的事情
不必要的复杂性：过分设计
不必要的重复：滥用鼠标
晦涩性：混乱的表达
原则：
- 单一职责原则 the single responsibility principle
- 开放-封闭原则 the open-close principle
- Liskov替换原则 the Liskov substitution principle
- 依赖倒置原则 the dependency inversion principle
- 接口隔离原则 the interface segregation interface
敏捷开发人员如何知道要做什么？
- 遵循敏捷实践去发现问题；
- 应用设计原则去诊断问题
- 应用适当的设计模式去解决问题
单一职责原则 simple responsibility principle
内聚性——一个模块组成元素之间的功能相关性。
就一个类而言，应该仅有一个引起它变化的原因；
例如把game 和 scorer分离，之前game即要跟踪当前比赛，又要计算得分。每个职责的变化都是一个轴线。如果一个类承担的多于一个职责，那么引起这个类变化的原因就有多个
如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会抑制这个类完成其他职责的能力。
开放-封闭原则
对于扩展，是开放的
对于更改，是封闭的
关键是抽象！！！
Liskov替换原则
子类型必须能够替换掉他们的基类型
从行为的角度看 A是不是 is-a B，例如我们认为正方形是一种特殊的长方形。
但在结算面积的时候，设置宽为4，长为5，长方形的面积是4*5，而如果设置了正方形长为4，宽为5，面积，，，就不是4*5这么算的了
提取公共部分
派生类中添加了其他类不会抛出的异常，也是违反了lsp原则
Is-a含义过于宽广，子类型的正确定义是：可替换性的“
依赖倒置原则 dip
高层模块不应该依赖于低层模块，二者都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象
- 任何变量都不应该持有一个指向具体类的指针或者引用
- 任何类都不应该从高具体类派生
- 任何方法都不应该复写它的任何基类中已经实现的方法
高层策略需要和低层实现进行分离
接口隔离原则
如果类的借口不是内聚的，就表示该类具有胖的接口
第三部分 薪水支付案例研究
系统需求点
用例分析，列举，异常情况
介绍熟悉一些常见设计模式，monostate倒是之前没见过的模式，从行为上的单例
第一次迭代开始
规格说明，与客户交谈中的一些记录，基本需求
基于用用例分析，考虑下系统的行为
进行用例分析的时候，关注素材和验收测试，找出系统的用户会执行的操作种类。
通过用例设计了系统核心模型图
实现，uml作为交流媒介，草图
测试优先
打包，包的设计原则
重用发布等价原则、共同重用原则、共同封闭原则、包内聚兴总结、稳定性包的耦合性和原则、
气象站案例研究
todo
ETS案例研究
todo